Modern telecommunications networks provide telephone users with a myriad of features in addition to performing their primary function of placing calls between users. Features such as call waiting, caller identification, and caller call back are now standard features offered by most telephone service provides, and thus the telecommunications networks of these service providers must be configured to support these and other features such as handling calls from wireless users.
FIG. 1 is a functional block diagram of a conventional telecommunications network 100 utilizing a global telecommunications standard known as “SS7,” which stands for “Common Channel Signaling System No. 7.” The SS7 standard defines protocols for defining how network elements in the public switched telephone network (PSTN) communicate over digital communications networks to provide wired and wireless call setup, routing, and control. The PSTN is the international telephone system that utilizes copper wires and analog signals to represent voice data and place calls between users, and the telephone service provide by this system is known as plain old telephone service (POTS). Thus, the network 100 utilizes network elements of the PSTN in addition to digital communications networks to place calls and provide various advanced features to users.
The network 100 includes service switching points (SSPs) 102 and 104 that operate to originate or terminate calls between users, which are represented by telephones 106, 108. Each SSP 102 and 104 communicates SS7 signaling messages according to the SS7 standard to other SSPs in the network 100 to setup, manage, and release voice circuits in the PTSN required to complete a call. The network 100 further includes signal transfer points (STPs) 110, 112 that route SS7 signaling messages to an appropriate point in the network 100 based on routing information contained in the message. In this way, each STP 110, 112 functions as a network hub and thereby eliminates the need for direct links between points in the network 100. The network 100 further includes service control points (SCPs) 114 and 116, each of which functions as a centralized database that determines how to route particular calls, such as calls having an 800 or 888 area code. In operation, one of the SSPs 102 and 104 originates a query message that is communicated to one of the SCPs 114 and 116. In response to this query message, the SCP 114 and 116 receiving the query message communicates a response message to the originating SSP 102 and 104 that contains routing information associated the call.
A number of service providers typically provide service through the network 100, and these service providers are constantly trying to improve the performance of the network and to add new or enhance existing features for their customers. To make such modifications typically requires a service provider to modify software executing on various points in the network. The software executing on the SSPs 114 and 116 typically provides most of the advanced features offered by a service provider and supported by the network 100, and thus a service provider must modify this software to add or change such features. On behalf of a service provider, a service developer 118 typically accesses computer systems (not shown) forming the SSPs 114 and 116 to modify the appropriate software and thereby modify the services executed by this software.
Each service is a program on the SSP 114 and 116 that executes a particular service logic flow. While these service programs can be written in a variety of different languages, many are based upon a model known as the service independent building block (SIB) model, where SIB is a term defined by the International Telecommunication Union (ITU) Telecommunication Standardization Sector (ITU-T). With this model, an SIB is a unit of service logic that performs a simple function, such as playing an announcement or incrementing a counter, and programs are formed by interconnecting number of SIBs. Libraries of SIBs have been defined, and the SIBs in these libraries are interconnected to form the desired service program and thereby provide the desired service. Associated with each SIB are inputs, outputs, and events, and the SIBs are interconnected using their events. For example, if there are three SIBs designated SIB1, SIB2, and SIB3, and SIB1 generates events A, B, and C, then SIB1 can be connected to SIB2 for event A and to SIB3 for events B and C.
To modify an existing service the service developer 118 must modify the service logic flow defined by the interconnected SIBs forming the corresponding program. Similarly, to develop a new service the service developer 118 must interconnect SIBs to perform the desired service logic flow. Current programs which may be utilized by the service developer 118 to implement desired modifications to an existing service or to develop a new service make the process difficult for a variety of reasons. First, current programs do not provide a sophisticated graphical user interface that allows the developer 118 to easily modify existing and generate new service programs. Also, current programs do not provide the developer 118 with an easy way to reuse repeated service logic sub processes within a given service program and among other service programs. For example, a group of SIBs may be interconnected in the same way in several different locations within the same service program, and may be used a number of different times in different service programs. The developer 118 must independently input this group of SIBs each time required, and test and debug each occurrence to ensure they have been input properly.
Another issue that arises currently with the SIB model involves maintaining proprietary rights in service programs. The interconnected SIBs that collectively form a service program are referred to as a service graph, and this service graph is akin to the source code of the service program. The service developer 118 may not be associated with the service provider and may be developing the service program for sale to a number of different service providers. In this situation, the service developer 118 ideally does not want to provide the service provider with access to the service graph, which represents the key piece of intellectual property generated and owned by the developer 118. Current programs, however, do not provide the developer 118 with an easy way of downloading or “deploying” a developed service program onto the SCP 114 and 116 without providing the serviced provider access to the service graph.
There is a need for a program and system for easily and efficiently designing and deploying service programs written using the SIB model.